The present invention relates to an information processing apparatus, an information processing method, a program, and a recording medium. More particularly, the invention relates to an information processing apparatus, an information processing method, a program, and a recording medium for carrying out processes associated with encryption.
It is becoming commonplace for diverse kinds of apparatuses to exchange digital data therebetween. Given the trend, it has become necessary to take measures against illicit uses of digital data which, by nature, does not corrupt in quality (i.e., picture and sound quality) when used or copied legitimately or otherwise (e.g., refer to Patent Document 1).
With DVD (digital versatile discs) and similar recording media gaining widespread acceptance today, it is easy to record a very large amount of data like a movie onto one piece of such media (e.g., disc) as digital information. Where movie information or similar data can be recorded as digital information, it is becoming all the more important to prevent illegal copying to protect copyright holder's interests.
DVD videos (i.e., video content-packed DVD) adopt CSS (Content Scramble System) as copyright protection technology. FIG. 1 is a block diagram showing a structure of a recording medium on which data encrypted by the CSS technology is recorded, along with a structure of an apparatus for reproducing data from that medium.
FIG. 1 indicates a disc 11 as a typical recording medium. The disc 11 retains a secured disc key 21 for identifying the disc 11, an encrypted title key 22 embedded in data at predetermined intervals, and scrambled data 23. Illustratively, if a movie is recorded on the disc 11, the title key 22 is provided illustratively for each chapter.
The disc key 21 and title key 22 are recorded in encrypted format (or in a manner resistant to abusive retrieval) on the disc 11. The data 23 is scrambled through the use of the title key 22 when recorded on the disc 11.
A player 12 reproduces the data 23 by reading keys and data from the disc 11. The player 23 has decryption devices 32 and 33, a descrambling device 34, and a decoder 35. The player 12 also has a management device (not shown) that manages a master key 31.
The decryption device 32 decrypts the disc key 21 read from the disc 11 by use of the master key 31, and supplies the decrypted disc key 21 to the decryption device 33. The title key 22 retrieved from the disc 11 is also supplied to the decryption device 33. Using the decrypted disc key 21, the decryption device 33 decrypts the encrypted title key 22. The decrypted title key 22 is fed to the descrambling device 34. The data 23 retrieved from the disc 11 is also fed to the descrambling device 34.
The data 23 to be read from the disc 11 and supplied to the player 12 has been compressed by a predetermined compression standard (e.g., MPEG (Moving Picture Experts Group) standard) before being scrambled by use of the title key 22. The descrambling device 34 descrambles the data 23 using the title key 22.
The descrambled data 23 is supplied to the decoder 35. The decoder 35 decodes the data 23 from the descrambling device 34 in accordance with a predetermined decoding standard (e.g., MPEG standard). The decoded data 36 is supplied to a display unit or like equipment, not shown.
The player 12 shown in FIG. 1 is illustratively a device dedicated to the reproduction of data from the disc 11 such as DVD. Alternatively, the dedicated player 12 may be replaced by a personal computer capable of reproducing data from the disc 11.
FIG. 2 shows a structure of a setup in which the disc 11 such as DVD is played illustratively by a personal computer or similar equipment. In this setup, a drive unit 51 reads data from the disc 11, and a host 52 processes the data read out by the drive unit 51. The drive unit 51 and host 52 shown in FIG. 2 include functions that may be implemented by application software.
As in the setup of FIG. 1, the disc 11 retains the disc key 21, title key 22, and data 23. The drive unit 51 is structured to include an authentication processing device 62 and bus encryption devices 62 and 63.
The host 52 has an authentication processing device 71, bus decryption devices 72 and 73, decryption devices 74 and 75, a descrambling device 76, and a decoder 77. The host 52 also has a management device (not shown) that manages the master key 31.
The authentication processing device 51 of the drive unit 51 and the authentication processing device 71 of the host 52 authenticate one another. Only when the process of mutual authentication is normally completed, can data be sent and received between the drive unit 51 and the host 52. Following the successful authentication process, the authentication processing devices 61 and 71 issue a key called a session key each (for shared use).
After the normal authentication process, the disc key 21 read from the disc 11 is encrypted by the bus encryption device 62 of the drive unit 51. The bus encryption device 62 is also supplied with the session key issued by the authentication processing device 61. Using the session key, the bus encryption device 62 encrypts the retrieved disc key 21 and outputs the encrypted disc key 21 to the host 71.
Likewise, the bus encryption device 63 encrypts the title key 22 read from the disc 11 by use of the session key issued by the authentication processing device 61, and outputs the encrypted title key 22 to the host 52. The data 23 retrieved from the disc 11 is supplied from the drive unit 51 directly to the host 52.
The bus decryption device 72 of the host 52 decrypts the encrypted disc key 21 sent from the bus encryption device 62 of the drive unit 51 through the use of the session key issued by the authentication processing device 71. The decrypted disc key 21 is fed to the decryption unit 74. The decryption unit 74 is also fed with the master key 31. Using the master key 31, the decryption device 74 decrypts the disc key 21 supplied from the bus decryption device 72 and sends the decrypted disc key 21 to the decryption device 75.
The decryption device 75 is also supplied with the title key 22 from the bus decryption device 73. The title key 22 has been decrypted by the bus decryption device 73 using the session key issued by the authentication processing device 71.
The decryption device 75 decrypts the encrypted title key 22 using the decrypted disc key 21. The decrypted title key 22 is supplied to the descrambling device 76. The descrambling device 76 is also supplied with the data 23 read from the disc 11.
The data 23 retrieved from the disc 11 has been compressed by a predetermined compression algorithm and scrambled by use of the title key 22. The descrambling device 76 first descrambles the data 23 using the supplied title key 22.
The descrambled data 23 is supplied to the decoder 77. The decoder 77 decodes the supplied data 23 by a predetermined decoding standard (e.g., MPEG standard). The decoded data 36 is supplied to a display unit or like equipment, not shown.
As described, the drive unit 51 loaded with the disc 11 and the host 52 for processing data held on the disc 11 authenticate one another before proceeding to reproduce the data 23 retrieved from the disc 11. Following a successful process of authentication, encrypted keys and data are sent and received between the drive unit 51 and the host 52.
It should be noted that data is actually sent and received between the drive unit 51 and the host 52 only after the authentication process. That is because the drive unit 51 and the host 52, connected by an appropriate bus (not shown), are designed to prevent the data from getting tapped illicitly from that bus.
Given below with reference to the flowchart of FIG. 3 is an additional description of the authentication process carried out between the authentication processing devices 61 and 71. In step S11, a check is made to determine whether the disc 11 is loaded (i.e., set) into the drive unit 51. A standby state is maintained until the disc 11 is found loaded into the drive unit 51 in step S11 (i.e., the process of step S11 is repeated).
If in step S11 the disc 11 is found loaded into the drive unit 51, step S12 is reached. In step S12, the authentication processing devices 61 and 71 authenticate one another. Unless and until the process of mutual authentication is normally completed, the subsequent steps will not be carried out.
Following the successful mutual authentication process, the authentication processing devices 61 and 71 generate a session key each. In step S13, a check is made to determine whether the process of mutual authentication has normally ended and the session key generation is successfully completed. The process of step S12 is repeated until it is found complete in step S13. Thereafter, control is passed on to step S14.
In step S14, a state is established in which scrambled data is authorized to be sent and received (i.e., output from the drive unit 51). In this case, the scrambled data is the data 23 (FIG. 2) that is authorized to be output from the drive unit 51 to the host 52.
More description will be made of the “authorized” state below. Under instructions from the host 52, the drive unit 51 reads the data 23 in the authorize state. With such authorization yet to be made, the drive unit 51 does not output the data 23, and instead returns an error message upon receipt of an instruction from the host 52 to read (output) the data 23.
With the authorized state in effect and given the instruction from the host 52, the drive unit 51 retrieves the data 23 from the disc 11. The retrieved data 23 is output to the host 52.
Once the authorized state is established, reproduction of the scrambled data 23 is repeated unless an interrupt condition such as unloading of the disc 11 from the drive unit 51 takes place.
With the scrambled data 23 authorized to be output, step S15 is reached. In step S15, a check is made continuously to determine whether the disc 11 is unloaded from the drive unit 51. When the disc 11 is found unloaded from the drive unit 51, control is returned to step S11 and the subsequent steps are repeated.
Data reproduction is also terminated when the drive is reset or switched off. Step S11 is then reached again as needed and the subsequent steps are repeated.
As described, following the normal termination of mutual authentication between the drive unit 51 and the host 52, the drive unit 51 keeps reading the data 23 from the loaded disc 11 and outputting the retrieved data 23 to the host 52 until the disc 11 is unloaded. The process is continued unless and until another instruction is given by the host 52.
A brief comment will be made here on some known techniques of encryption performed by encryption equipment such as the bus encryption device 62. Varieties of encryption algorithms have been proposed. One such encryption (and decryption) algorithm called CBC (Cipher Block Chaining) is explained below.
The CBC encryption algorithm is a technique that involves exclusively ORing each block of data in unencrypted form with the preceding block in encrypted form so as to generate each encrypted block of data. FIG. 4 shows a typical circuit for encryption by the CBC algorithm.
The target data to be encrypted is turned into blocks in predetermined increments (e.g., 16 bytes if AES (Advanced Encryption Standard) is used as the block encryption scheme). A first block is supplied to an XOR circuit 101-1, a second block following the first block is fed to another XOR circuit 101-2, a third block following the second block is sent to another XOR circuit 101-3, and so on. There are provided as many XOR circuits as a predetermined number of stages (N stages in this example) so that blocks of data in unencrypted form may be input successively to the XOR circuits 101-1 to 101-N.
The first block output from the XOR circuit 101-1 is supplied to an encryption device 102-1. The encryption device 102-1 encrypts the supplied first block using a key Ek. Thus, the first block is encrypted.
The encrypted first block output from the encryption device 102-1 is also sent to the XOR circuit 101-2 for the exclusive OR operation with the second block. The result of the XOR operation is fed to another encryption device 102-2 that encrypts the supplied data using the same key Ek.
According to the CBC encryption, as outlined above, each block of data in unencrypted form is XORed with the preceding block in encrypted form. The resulting block of data is encrypted by use of a predetermined encryption key. The block of data thus encrypted is XORed with the next block of data. Thus each current block is chained to the preceding block successively to generate data in encrypted form.
Whereas the second and subsequent blocks of data are each XORed with the preceding block, the first block cannot be XORed with its preceding block which obviously does not exist. Thus an initializing vector (IV) is introduced and XORed with the first block.
Described below with reference to FIG. 5 is a decryption circuit (e.g., bus decryption device 72 (FIG. 2)) based on the CBC algorithm.
Encrypted data is turned into blocks in predetermined increments (e.g., 16 bytes if AES (Advanced Encryption Standard) is used as the block encryption scheme), as discussed above. A first block of data is supplied to a decryption device 122-1, a second block following the first block is fed to another decryption device 122-2, a third block following the second block is sent to another decryption device 122-3, and so on. There are provided as many decryption devices as a predetermined number of stages (N stages in this example) so that blocks of data in encrypted form may be input successively to the decryption devices 122-1 to 122-N.
The decryption devices 122-1 to 122-N decrypt the respectively input data using a key Dk each. The data output from the decryption devices 122-1 to 122-N are supplied to XOR circuits 121-1 to 121-N respectively. The XOR circuits 121-2 to 121-N are also supplied with the data fed to the respectively preceding decryption blocks 122-1 to 122-N-1.
As described, the decryption based on the CBC algorithm is accomplished when each target block of data in decrypted form is XORed with the preceding block in encrypted form.
While the second and subsequent blocks of data are each XORed with the preceding block, the first block cannot be XORed with its preceding block which obviously does not exist. Thus an initializing vector (IV) is introduced and XORed with the first block.
The foregoing description has given an outline of how encryption and decryption are typically executed.
[Patent Document 1]
Japanese Patent No. 3252706
Where the data 23 is to be reproduced from the disc 11 by the drive unit 51 in conjunction with the host 52 as shown in FIG. 2, the data 23 is authorized to be output from the drive unit 51 following the successful process of mutual authentication between the drive unit 51 and the host 52. The process was explained above in reference to the flowchart of FIG. 3.
Suppose that the host 52 starts up an application A and that the application A thus activated prompts the authentication processing device 71 to carry out the authentication process. In this case, normal execution of the authentication process by the application A with regard to the drive unit 51 brings about a state in which the data 23 is authorized to be read from the disc 11 and output by the drive unit 51.
In that state, the data 23 is authorized to be output continuously by the drive unit 51 unless and until the disc 11 is unloaded from the drive unit 51. Suppose now that with the authorized state in effect, an application B is started up by the host 52 and that the application B, instead of the application A, starts giving instructions including one for reading out the data 23.
In that case, the drive unit 51 and the application B do not authenticate one another. However, because the drive unit 51 is held in the state in which the data 23 is authorized to be output, the data 23 is left being output from the drive unit 51 to the host 52 (i.e., application B). As a result, the data 23 can be recorded by the application B to a hard disc drive (HDD) 141 as part of the host 52.
Although recording of the data 23 onto the HDD 141 is illegal, the drive unit 51 proceeds to output the data 23 under instructions from the application B. This kind of abuse has been left unchecked with existing setups.
The data 23 stored on the HDD 141 is scrambled and cannot be reproduced as is. Still, because there are applications for descrambling data, it is virtually impossible to prevent illicit uses of the data 23 once it is recorded to the HDD 141.
As described, once the authentication process is normally accomplished and the data 23 is authorized to be output from the drive unit 51, the data 23 becomes vulnerable to theft.
Other abuses of data are explained below with reference to FIG. 7. The drive unit 51 and the host 52 are interconnected by a suitable bus and exchange the data 23 therebetween over that bus. As in the case discussed above with reference to FIG. 6, the application A on the host side performs mutual authentication with the drive unit 51. After the normally completed process of authentication, the data 23 is authorized to be output from the drive 51.
If the host 52 has a monitor 151 for monitoring data that is sent and received over the bus, that monitor 151 can be used to acquire (i.e., monitor) the data 23 from the bus. In other words, the data 23 output from the drive unit 51 can be supplied both to the application A and to the monitor 151.
It is thus possible for the host 52 to store onto the HDD 141 the data 23 acquired by the monitor 151. This is another way in which the data 23 could be abused.
As described, existing setups could let the monitoring function be utilized to steal or otherwise abuse the data exchanged over the bus.
Methods have been proposed to encrypt the data 23 so that the data 23 exchanged over the bus will not be stolen from the bus. One such method is described here with reference to FIG. 8. In the ensuing description, the data output from the drive unit 51 to the host 52 will be referred to as transfer data 171.
The transfer data 171 is handled in data packets of 2,048 bytes (2K bytes) each. Where the drive unit 51 and host 52 are interconnected by a suitable bus as described above, a bus interface 183 for controlling the bus is installed to handle data in predetermined increments. Illustratively, if the bus interface 183 is based on ATAPI (AT Attachment with Packet Interface), it is stipulated that the data increment be 2,048 bytes.
If the transfer data 171 is assumed to occur in data packets of 2,048 bytes, each packet is made up of a 16-byte initializing vector IV and a 2,032-byte data part as indicated in FIG. 8. In this data packet, the 2,032-byte data part is encrypted by an encryption device 181. Although not shown in FIG. 8, the encryption device 181 encrypts each data part using a session key Ks issued by the authorization processing device 181 (see FIG. 2).
The encryption device 181 performs its encryption process illustratively through the use of the CBC algorithm. The CBC-based encryption requires that the encryption device 181 be structured internally as shown in FIG. 4. As explained above in reference to FIG. 4, the encryption device 181 also utilizes the initializing vector IV when carrying out the encryption. That is, given each data packet of the transfer data 171, the encryption device 181 encrypts the 2,038-byte data part using the 16-byte initializing vector IV included in the same data packet as well as the session key Ks issued by the authentication processing device 181.
The data packets encrypted by the encryption device 181 are each a 2,048-byte data packet that can be handled by the bus interface 183. Each data packet with its data part encrypted is supplied to a decryption device 182 of the host 52. The decryption device 182 decrypts the encrypted data using the initializing vector IV included in the supplied data packet and the session key Ks issued by the authentication processing device 71 (FIG. 2).
Although the host 52 receives the encrypted data, that data can be decrypted by the host 52 using the initializing vector IV furnished together with the data in question. In this manner, the host 52 can reproduce the data output from the drive unit 51.
When the data exchanged through the bus interface 183 is encrypted, the data will not be abused as long as it is not decrypted even if the data exchanged through the bus interface 183 is tapped. In this manner, misappropriation of data is supposed to be prevented. However, there are some problems with this scheme as will be outlined in the following description:
Referring again to FIG. 8, the initializing vector IV is part of the transfer data 171. When the initializing vector IV is to be included in the transfer data 171, the vector is written to the disc 11 together with other data. That means the initializing vector IV cannot be varied randomly (i.e., the initializing vector IV written on the disc must be used as is, without change).
It might be possible, with no initializing vector IV written on the disc 11, to have the drive unit 51 generate the initializing vector IV randomly so as to get the vector IV included in the transfer data 171. However, this is where a restricting condition is imposed: when the initializing vector IV is to be included in the transfer data 171, the vector must be provided illustratively with a header and the like in distinction from the data to be encrypted.
Under that condition, the drive unit 51 may be arranged to generate randomly the initializing vector IV but is subject to certain constraints on the randomized vector generation. Ultimately, there is no guarantee that the drive unit 51 can always generate the initializing vector IV on a random basis (i.e., there may occur a fixed pattern during initializing vector generation).
If the initializing vector IV cannot be varied randomly, i.e., if a fixed pattern is expected to appear during initializing vector generation, there may be the following problem:
Illustratively, the format of e-mail has a fixed pattern made up of the recipient's address, the sender's address, a subject, and a message. If the data of that pattern (in plain text) is encrypted, the encrypted data also presents a pattern that may draw the attention of a third party (i.e., attacker). A third party could then proceed to decrypt at least in part the encrypted data.
In another example where music data is prepared for repeated reproduction, the preparatory encryption involves encrypting data in the same plain text repeatedly, which results in encrypted data having a repetitive pattern. As in the preceding example, the encrypted data presents a pattern that is vulnerable to abusive decryption.
Under these circumstances, where there is plain text data with a fixed pattern to be encrypted (e.g., for the same data to be encrypted a plurality of times), the first block of data is supplemented with an initializing vector IV so as to nullify any similar pattern that may appear in the encrypted data. Adding the initializing vector IV to the first block upon encryption prevents the same pattern as that in the plain text data block from taking shape, which makes eventual decryption more difficult. As another benefit, addition of the initializing vector IV at encryption time makes it easy to predict a single key that may be used to encrypt a large amount of data.
It is for these reasons that the initializing vector IV is often added to the first block of data before the subsequent blocks are encrypted.
Updating the initializing vector IV at suitable intervals makes it more difficult to determine whether given plain text data has a particular pattern. This contributes to preventing unscrupulous data substitution or falsification. (Reference: NIST Special Publication 800-38A 2001 Edition, Recommendation for Block Cipher Modes of Operation, Methods and Techniques, APPENDIX C Generation of Counter Blocks)
In other words, if the same initializing vector IV is used repeatedly, the practice cannot offer the benefit of periodically updating the vector IV described above. As a result, to use the same initializing vector IV repeatedly makes it difficult to determine whether given plaintext data has a particular pattern and cannot prevent data substitution or falsification.
Obviously, it is preferable to update the initializing vector IV as described above.
Where arrangements are made to update the initializing vector IV, methods such as one shown in FIG. 9 are worked out whereby data is sent and received. In the example of FIG. 9, the transfer data 191 is constituted by blocks of 2,048-byte data supplemented with a 16-byte initializing vector IV each. The added vector IV makes up a 2064-byte data block that can be sent and received through the bus interface 183.
When the initializing vector IV is added to the transfer data 191 (i.e., where the initializing vector IV is not included beforehand in the transfer data 191), the drive unit 51 can be arranged to generate the vector IV randomly. The randomly generated initializing vector IV is then added to the transfer data 191.
However, addition of the initializing vector IV to data signifies that a special sector size of 2,064 bytes (where IV=16 bytes) is introduced to the PC Drive Interface that handles data typically in increments of 2,048 bytes. What is created here is a nonstandard format that is not compatible with the environment of a personal computer (PC). The incompatible environment includes the commonly used ATAPI Device Driver, and UDF (Universal Data Format) FS Driver that handles sector sizes of 2,048 bytes or 4,096 bytes.
The incompatibility with the PC environment must be circumvented by making special modifications in terms of hardware and/or software. The exercise is costly and laborious. After the modifications, the speed of data processing is bound to be reduced.